1. Technical Field
The present invention relates generally to an improved data processing system and method. More specifically, the present invention is directed to a system and method for associating security information with information objects in a data processing system.
2. Description of Related Art
A reference monitor is an authorization and enforcement mechanism for authorizing a source to perform a particular action on a target. Many reference monitors make use of access control lists (ACLs) for performing such authorization. These ACLs identify, for each source, the targets that the source may access and the particular types of access that source is authorized to have, i.e. what actions the source may perform on the target.
Most modern reference monitors and security systems make authorization decisions by comparing “subject” security attributes and “target” security attributes against a set of security policy rules. Different data types are often assigned to the subject and target security attributes. One example illustrating these different data types is provided in the ISO 10181-3 Access Control Framework described at www.opengroup.org/onlinepubs/009609199/chap3.htm#tagfcjh—2. In this exemplary architecture, four different roles, or data types are provided, i.e. initiators (sources), targets, access control enforcement functions, and access control decision functions. This type difference between subject security attributes and target security attributes adds unnecessary complexity to the security policy evaluation process in that each possible combination of subject and target security attributes must be provided with a security policy rule in order to be evaluated correctly during runtime.
Additionally, the target security attribute data types are typically based on the set of operations which may be performed on the target resource. Thus, the target security attribute type creates an unnecessary linkage between the structure of the application which manages target resources and the structure of the security policy evaluation subsystem. This in turn creates unnecessary complexity in the security policy evaluation subsystem since the security policy must now take into consideration the semantics of data manipulation by the applications and the semantics of security policy evaluation.
Moreover, distinguishing the data types of subject security attributes and target security attributes creates an asymmetry in the security policy which restricts the security evaluation subsystem to control transfers from the subject (source) to the target, i.e. the object that will be receiving information, but does not allow it to control transfers from the target to the source. In other words, separate policies must be established for each type of transfer between each pair of subject and target, thereby leading to even more complexity of the security policy evaluation subsystem.
For example, assume that there are two Objects A and B. In order to cover all possible transfers between Objects A and B, four policies must be established and evaluated when controlling transfers of information: (1) A can (or cannot) write to B, (2) A can (or cannot) read from B, (3) B can (or cannot) read from A, and (4) B can (or cannot) write to A.
Many different mechanisms have been devised for controlling the transfer of information between elements of a data processing system. For example, in U.S. Pat. No. 6,766,314 issued to Rodney Burnett, entitled “Method for Attachment and Recognition of External Authorization Policy on File System Resources,” an external security database containing auxiliary attributes for objects in a file system is generated. During a file access attempt, an identifier of the file is matched against a set of protected files in the security database. If the file is not in the database, then there is no protection of the file and the requester is allowed to access the file. If there is a match in the database, the file is protected and a determination as to whether a requester will be allowed to access the file is made based on a set of security rules defined in the external security attribute.
With the mechanism of U.S. Pat. No. 6,766,314, a resource manager comprises components for retrieving a security policy, components for intervening in access to the files to be protected, and components collecting access conditions such as the accessing user and the attempted action. Based on the security policy, the file being accessed, and the access conditions, a decision is rendered regarding authorization to access the file.
Thus, in the mechanism of U.S. Pat. No. 6,766,314, authorization to access a file is tied to the identity of the user and the action being attempted. Thus, the actions being performed are tied to the entities performing the actions and the file being accessed. As mentioned above, this creates an unnecessary linkage between the structure of the application which manages the files and the structure of the security policy evaluation subsystem.
A similar mechanism is described in U.S. Pat. No. 5,765,153. In U.S. Pat. No. 5,765,153, a reference monitor is provided which enforces policies based on subject identities, object names, and actions defined by the interface of the protected object. Again, by basing authorization decisions on the identities of the entities and the types of actions being performed on one identified entity by another identified entity, an unnecessary linkage is generated that complicates the implementation of a security policy evaluation subsystem.